It is desirable for telecommunications network operators that provide IP connectivity (i.e. that provide an IP-CAN) to be able to allow trusted third parties to provide “over-the-top” (OTT) services to subscribers/users. For a number of reasons, it is also desirable that these third party service providers (3PSP) are able to cooperatively interact with the network operator. For example, a 3PSP may wish to cooperate with a network operator in order to implement charging, revenue sharing, enhanced service delivery, etc. To do so, the service provider and the network operator are required to be able to identify subscribers/users to each other, by using the same identifier to identify a subscriber/user even when they operate in different authentication domains.
In existing network deployments, this identification of subscribers/users is typically achieved by the IP-CAN deriving an identifier for a subscriber/user when an IP-CAN session has been established, and linking this subscriber identifier with application protocol messages that are being used to deliver a third party service over the established IP-CAN session. For example, a GSM or UMTS mobile network can determine the subscribers Mobile Subscriber ISDN Number (MSISDN), or an IP Multimedia Subsystem Public User Identity (IMPU) of the subscriber, and can then add a header field into the application/signalling protocol messages that includes this subscriber identifier. To do so, a proxy in the IP-CAN is required to receive the application/signalling messages sent towards the 3PSP by the subscriber, perform the insertion of this header field into the application/signalling protocol messages, and forward the signalling protocol messages towards the 3PSP. For example, a SIP proxy server such as a P-CSCF can insert the P-Asserted-Identity header field into SIP messages, and a HTTP proxy can insert the X-3GPP-Asserted-Identity header field into HTTP messages. The 3PSP thereby receives the subscriber identifier from the network operator, and can use this subscriber identifier when communicating with the network operator in order to implement charging, billing, enhanced service delivery, or any other matters.
FIG. 1 illustrates schematically the interaction between a conventionally deployed IP-CAN and a 3PSP in accordance with the scenario referred to above. An IP-CAN 100 implemented by operator A provides IP connectivity to a subscriber's device/terminal 101 (e.g. mobile phone, Smartphone, laptop computer, desktop computer etc.). The subscriber can therefore connect to an Application Server 102 of a 3PSP 103 via the public internet 104. An edge router 105 within the IP-CAN 100 forwards IP packets to/from the device 101. For example, the edge router 105 could be a PDN Gateway (P-GW) of an LTE network, or a GGSN of a GPRS network. A proxy server 106 is also provided within the IP-CAN 100 for proxying application/signalling messages. For example, the proxy server 106 could be a SIP proxy server (e.g. a P-CSCF in IMS), a RTSP proxy server, or a HTTP proxy server, depending upon the protocol used. The proxy server 106 routes and forwards signalling messages, including those intended for the 3PSP 103. In current solutions, the proxy server 106 obtains an identifier for the subscriber from a source within the IP-CAN 101, and inserts an application information element into the signalling protocol messages in order to provide the subscriber's identity to the 3PSP 103. The IP-CAN may also contain a Network Address (and Port) Translation (NAT) function 107. A NAT function 107 translates internal IP addresses (i.e. those allocated within the operator's network) to external IP addresses (i.e. used in the public Internet). Depending on the particular network deployment, the NAT function 107 can be co-located with the edge router 105. In addition, it is possible that several cascaded NAT functions can be implemented within an IP-CAN, with each NAT function providing translation between addresses used in different sub-networks within the IP-CAN.
With these conventional procedures for providing a subscriber identity to a 3PSP, a problem arises when the communication between the subscriber/user and the 3PSP is encrypted. In this situation, the proxy server 106 does not have means to decrypt the signalling protocol messages exchanged between the device 101 and the application server 102 of the 3PSP 103, and it therefore cannot add new header fields into the forwarded messages. As a result, the 3PSP 103 receives the signalling protocol messages, but is unable to determine the identity of the subscriber/user to which the messages refer. Among other things, this prevents the 3PSP from cooperating with the network operator using the subscriber identifier. The present invention aims to overcome this problem.